pp108 : Fields of MDM Default Sniffers

Fields of MDM Default Sniffers
This topic describes the fields of the default sniffers provided by Process Platform.

Trigger Sniffer


A change in a spoke data that uses trigger-based sniffing, triggers a change request to the hub. As the hub also uses trigger-based sniffing, any change in its data triggers a change request to all subscribed spoke. Therefore, any data update to a spoke will return to it after being propagated to the hub, and thus will result in an infinite loop. This is prevented by providing the hub with a mechanism to identify the individual spokes that use trigger-based sniffing so that the hub does not return a change request to the spoke from where it came.

To facilitate identification, you must create a new database user, referred to as theMDM DB User, with appropriate access rights for each spoke that will use trigger-based sniffing. The user name will be used by the hub for its transaction with the spoke.

Note: Ensure that the MDM User has Select, Insert, Update, and Delete permissions on any type of data repositories.
The following fields appear when the Trigger sniffer is selected:

Field Names

Description

Record Type

This field contains the following options:

  • All Changes - Specifies that the audit table must record all changes to the data entity
  • Last Change - Specifies that the audit table must record just the last change made to the data entity

MDM User

Specify the user who has access to the database. The user's access permission on the database must be the same as the type of spoke defined. If the spoke is send only, the user must have read permission on the database. If the spoke is receive only, the user must have write permission on the database. If the spoke is send and receive or if it is a hub, the user must have read and write permissions on the database.Note that this user is required only for trigger based sniffers on the entities.

Generic Timestamp Sniffer

The following fields appear when the Generic Timestamp sniffer is selected:

Field Names

Description

Column Name

Specify the column name in the data store that contains the time stamp.

Correction Factor (in ms)

Specify the time for correction factor. It is possible that the data entities are changed immediately after or during data integration. The next integration must accommodate this change. Therefore, we include a correction factor so that the next integration starts a little earlier than the specified time.

Sniffer Start Date

Specify the start date when sniffing must begin. When the date is selected from the calendar, the current time is also selected. You manually modify the time according to your requirements.

Oracle10g Sniffer

The following fields appear when the Oracle10g sniffer is selected:

Field Names

Description

Record

This field contains the following options:

  • All Changes - Specifies that the audit table must record all changes to the data entity
  • Last Change - Specifies that the audit table must record just the last change made to the data entity

Correction Factor (in ms)

Specify the time for correction factor . It is possible that the data entities are changed immediately after or during data integration. The next integration must accommodate this change. Therefore, we include a correction factor so that the next integration starts a little earlier than the specified time.

Start Time

Specify the start date when sniffing must begin. When the date is selected from the calendar, the current time is also selected. You manually modify the time according to your requirements.

Message Queue

The following fields appear when the Message Queue sniffer is selected:

Field Names

Description

JMS Vendor

Specify the type of JMS vendor. This can be Sun, IBM or Open JMS

JNDI Parameters tab

Specify the location where the JMS administered objects can be found (Local file system, LDAP, or any other location). For any location, type the Class Name and the URL. If required, provide the User Name and Password for authentication.

Receiver Details tab


  • Under the Receiver Details tab, select the type of JMS administered objects you are using (Queue type or Topic type). For each, type the Factory Lookup Name and the Topic Lookup Name.
  • Under the Receiver Details tab, select the message processing mechanism you want to use. For the default process, type the Event Name and the conditions for Insert, Update, and Delete operations. For the custom process, type the class name to be used.

To further understand the fields for this sniffer, refer to the example.

Comparator Sniffer

The Comparator sniffer compares the data entity at different time slots and checks for changes in the data. There are no parameters that must be configured for this sniffer. However, it is mandatory to configure the sniffer schedule. For information on fields in sniffer schedule window, refer to Fields in Sniffer Schedule.

The Comparator sniffer is active only once in the time period of the entire schedule. Once the Comparator sniffer has sniffed in that interval, it will not sniff again until the schedule is triggered. If the sniffer has already sniffed once in that interval, it will not pick the latest changes even if the schedule is active and there are new changes coming in. It must wait until the next schedule is triggered.

The Comparator sniffer enables data comparison using snapshots. A snapshot is a set of data, which is used to compare different data sets to determine the modified data set. The pull method defined on a particular entity is used to read the data and create a data snapshot. If a custom Web Service is used, the Web Service must ensure that data is always pulled in the same order such as a sorted order. If a different set of data is read each time data is pulled, different snapshots are created. In this case, comparison of the data sets will yield unknown results.